Today, there are many applications in which data is broadcast or multicast to a group of individual receivers via some communication channel. Terrestrial and satellite television and radio transmissions are obvious examples. In the Internet, streaming video and audio signals can be broadcast or multicast to individual Internet terminals using the Internet Protocol (IP). In the very near future, technologies such as those defined by 3GPP will allow the broadcasting/multicasting of streaming IP data to mobile handsets. Subscribers will be able to listen to music and watch concerts and football games via their mobile handsets.
For a number of reasons, it is often necessary to be able to send multicast signals (it will be appreciated that reference here to “multicast” is only by way of example and that the following discussion applies equally to broadcast signals) in such a way that only authorised receivers can make use of the signals. The nature of the material may make this necessary, for example to prevent children from viewing adult content. In the case of a subscription service, it may be necessary to prevent receivers who have not paid for a service from using a received signal.
3GPP is currently developing a multicast system called MBMS (Multimedia Broadcast/Multicast System) in which a service key (MSK) is distributed from a BM-SC (Broadcast/Multicast Service Center) to UEs (User Equipments) that have joined a specific service. The MUK is a key shared between the BM-SC and a specific UICC, i.e., each UICC has its own MUK. The UEs use this service key to access the multicast data by decrypting subsequently sent traffic encryption keys (MTK) encrypted with the MSK. The MBMS system requires that the UE has a trusted module (i.e. trusted by the BM-SC) where the MSK is stored. The communication between the trusted module (here called Universal IC Card or UICC) and the BM-SC is protected with a key called MUK (MBMS User Key). The mobile equipment (ME) does not know the MUK nor the MSK, but is provided with the MTK following receipt and decryption by the UICC.
One of the charging models for 3GPP is that the users will be charged for provision of this MSK. In order to provide accurate and fair charging it is important that the service key is delivered reliably to the UE (i.e. the UE needs to acknowledge the reception of the MSK), otherwise it could happen that a UE might be out of coverage at the time of service key delivery and would not get the service key, yet would be charged for the service. MBMS therefore allows for the possibility that the UICC return a service key reception acknowledgement to the BM-SC upon successful receipt by the UICC of the MSK. It is however possible for a malicious UE implementation to refrain from sending the service key reception acknowledgement to the BM-SC in order to avoid being charged. Not even the protected nature of communications between the UICC and BM-SC (achieved using the MUK) guarantees that the reception acknowledgement gets through to the BM-SC since the acknowledgement must travel via the ME that could be malicious and drop it.